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Damage  Control  Automation  for  Reduced  Manning  (DC-ARM) 
Supervisory  Control  System  Software  Summary  Final  Report 

1.0  Introduction 

The  Damage  Control  Automation  for  Reduced  Manning  (DC-ARM)  Program  was  started 
in  1997  to  develop  and  demonstrate  technology  for  enabling  reductions  in  the  manning 
needed  for  damage  control  (DC)  while,  at  the  same  time,  improving  DC  performance. 
The  DC-ARM  Program  is  sponsored  by  the  Office  of  Naval  Research  (ONR)  and 
managed  by  the  Naval  Research  Laboratory  (NRL).  Testing  to  support  DC-ARM 
development  and  DC-ARM  demonstrations  was  conducted  aboard  NRL's  fire  research 
test  ship,  the  ex-USS  Shadwell'm  Mobile,  AL  [1]. 

The  DC-ARM  Program  has  been  a  multi-year  effort  designed  to  evaluate  and 
demonstrate  incremental  reductions  in  DC  Manning  corresponding  to  increases  in 
automation  and  doctrine  improvement  through  scientifically  based  experimentation. 

The  DC-ARM  technologies  selected  to  enable  reduced  DC  manning  included: 

•  Water  mist  for  fire  suppression  and  fire  containment. 

•  Instrumentation  for  fire  detection  and  fire  characterization. 

•  Fire  main  distributed  controls  for  robust,  survivable  isolation  of  fire  main 
ruptures. 

•  Smoke  ejection  system  for  clearing  smoke  on  the  DC  deck. 

•  Access  closure  monitoring  to  improve  situation  awareness. 

•  Video  installed  in  most  spaces  for  compartment  monitoring  and  to  reduce 
investigation  workload. 

•  Supervisory  control  system  (SCS)  to  enable  effective  situation  awareness  and 
overall  control  of  the  DC  response. 

•  New  doctrine  developed  to  integrate  with  new  technology 

The  DC-ARM  technology  demonstrations  included  a  variety  of  peacetime  fire  scenarios 
(self  initiated  fires)  and  wartime  damage  scenarios.  The  wartime  damage  scenarios 
replicated  the  damage  expected  from  a  anti-ship  missile  hit,  one  of  the  most  stressing 
DC  events.  The  wartime  damage  included  structural  damage,  damage  to  accesses,  fire 
main  damage,  damage  to  instrumentation  and  control  systems,  major  fires,  smoke,  and 
flooding.  Fleet  personnel  actively  took  part  in  the  live  fire  and  flooding  tests  to  exercise 
the  DC-ARM  systems  and  reduced  manning  doctrine  in  a  realistic  shipboard  damage 
environment. 

References  [2]  and  [3]  are  NRL  reports  of  the  FY98  and  FYOO  DC-ARM  demonstrations 
respectively.  Reference  [4]  reports  the  first  phase  of  the  SCS  development.  This  report 
is  a  summary  of  the  DC-ARM  SCS  development;  it  addresses: 
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•  Performance  demonstrated, 

•  SCS  functions  from  the  perspective  of  DC  personnel, 

•  SCS  architecture  and  application  program  functions, 

•  A  methodology  for  engineering  the  architecture  distributed  control  systems, 
and 

•  Conclusions  and  recommendations. 

As  used  in  this  report,  an  SCS  is  defined  as;  A  system,  automated  to  some  extent,  that 
monitors  and  controls  multiple  ship  systems  and  enables  a  human  supervisor  to  interact 
with  the  ship  systems  through  a  human-computer  interface  and  to  manage  human 
actions  so  that  the  responses  of  the  systems  and  the  actions  of  the  personnel 
complement  one  another. 

2.0  Performance 

The  SCS,  combined  with  the  other  DC-ARM  technology,  enabled  effective  management 
of  the  DC  response  during  the  FYOl  Demonstration.  The  performance  demonstrated  is 
summarized  in  Table  1  and  described  briefly  below  for  Casualty  Characterization,  Fire 
Containment,  Fire  Control,  Fire  main  Rupture  Isolation,  and  DC  Management. 

2.1  Casualty  Characterization 

The  information  provided  by  the  SCS  significantly  reduced  the  time  required  to  identify 
the  Primary  Damage  Area  (PDA).  The  Primary  Damage  Area  is  defined  as  the  area 
subject  to  the  immediate  effects  of  the  weapons  in  particular,  structural  damage, 
equipment  damage  or  personnel  injury  caused  by  weapon  blast  or  fragments  from  the 
weapon  [5].  Defining  the  PDA  historically  has  involved  dispatching  investigators  and 
waiting  for  their  reports  of  damage;  this  typically  has  taken  15  minutes  or  more. 

During  the  Baseline  Demonstration,  without  the  SCS,  it  took  an  average  of  18  minutes 
to  define  the  PDA.  Until  the  PDA  has  been  defined,  the  DC  team  cannot  plan  and 
execute  an  effective  course  of  action.  With  the  information  and  decision  aids  provided 
by  the  SCS,  it  took  less  than  4  seconds  to  display  the  PDA.  With  this  more  rapid 
casualty  characterization,  DC  actions  can  be  executed  much  sooner.  For  example, 
water  mist  was  actuated  to  contain  the  fire  within  25  seconds  after  weapon  impact. 

The  SCS  defines  the  PDA  as  all  contiguous  compartments  that  the  SCS  believes  were 
affected  by  the  same  casualty-initiating  event.  To  determine  which  compartments  are 
included  in  the  PDA,  the  SCS  looks  at  all  available  environmental  sensors  and 
categorizes  the  data  and  sensor  as  normal  and  functioning,  abnormal  and  functioning, 
or  nonfunctioning.  Generally,  contiguous  compartments  with  abnormal  data  or 
nonfunctioning  sensors  are  categorized  as  belonging  to  the  PDA. 
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Table  1.  Summary  of  DC-ARM  Key  Performance  Demonstrated 

Shading  denotes  meeting  DC-ARM  Objective 
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The  times  shown  are  the  averaged  time  for  all  wartime  tests  in  a  test  series. 

Data  presented  in  Table  1  obtained  from  the  following  references: 

DC-ARM  Objectives  and  Baseline  Demo  performance  data  from  Reference  2. 

FYOO  Demo  performance  data  from  Reference  3. 

FYOl  Demo  performance  data  from  working  notes  for  preparation  of  report  of  the  FYOl  Demonstration. 


2.2  Fire  Containment 


In  the  FYOl  Demonstration  within  25  seconds  after  weapon  impact,  the  SCS  actuated 
the  water  mist  system  in  the  compartments  surrounding  the  PDA  to  contain  the  fire. 
The  SCS  monitored  the  ambient  conditions  in  each  boundary  compartment  and 
automatically  actuated  water  mist  when  the  boundary  temperature  threshold  was 
exceeded  in  a  compartment.  After  the  initial  actuation,  water  mist  was  actuated 
intermittently  in  the  compartment  to  minimize  the  amount  of  water  used.  This 
actuation  approach  was  used  to  reduce  mist,  to  improve  visibility  and  to  minimize 
collateral  water  damage.  The  SCS  also  provided  recommendations  that  the  DC  Officer 
dispatch  boundary  men  to  locations  that  required  fire  boundaries  that  were  not  covered 
by  the  water  mist  system.  With  the  rapid  information  provided  by  the  SCS,  the  DC 
Officer  could  establish  manual  fire  boundaries  (person  on-scene  with  hose,  ready  to 
cool  bulkheads)  in  less  than  5  minutes.  During  the  Baseline  Demonstration  without  the 
SCS,  it  took  over  19  minutes  to  set  vertical  boundaries  allowing  the  potential  for  fire 
spread.  Previous  fire  tests  have  demonstrated  that  vertical  fire  spread  can  occur  in  less 
than  ten  minutes  over  a  post-flashover  fire  compartment  [2].  With  only  water  mist  to 
contain  the  fire,  some  small  fires  ignited  in  boundary  spaces  where  combustible 
material  was  in  direct  contact  with  a  bulkhead  bounding  the  PDA.  The  water  mist 
controlled  such  small  fires  until  investigators  arrived,  extinguished  the  fire,  and  removed 
the  combustible  material  from  the  heated  surfaces. 

2.3  Fire  Control 

Using  information  and  decision  aids  in  the  SCS,  the  DC  Officer  directed  a  methodical 
response  to  damage  that  utilized  manpower  efficiently  and  proved  to  be  very  effective 
at  controlling  damage  spread.  In  less  than  30  minutes,  the  DC  teams  accessed  the  PDA 
and  controlled  fires.  Fires  in  the  PDA  were  extinguished  within  40  minutes.  This 
performance  exceeds,  substantially,  the  performance  demonstrated  in  any  non-DC-ARM 
test  aboard  the  SHADWELL  in  over  a  decade  of  DC  testing  with  Fleet  personnel.  Table 
1  summarizes  the  performance  demonstrated. 

The  substantial  improvement  in  performance  for  controlling  fire  is  attributed  to  the  fire 
containment  systems,  automatic  fire  main  rupture  isolation,  the  enhanced  situation 
awareness  enabled  by  the  SCS,  and  the  decision  aids  provided  by  the  SCS.  Since  the 
fire  containment  was  mostly  automatic,  and  the  fire  main  rupture  isolation  was  fully 
automatic,  the  DC  Officer  was  able  to  devote  more  attention  to  fire  control.  The 
enhanced  situation  awareness  enabled  a  clear  understanding  of  where  the  fire  was  so 
that  the  fire  attack  could  be  planned  and  initiated  quickly  and  conducted  effectively. 
Finally,  the  SCS  decision  aids  provided  guidance  that  contributed  to  the  efficient, 
effective  use  of  limited  manpower. 
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In  the  wartime  scenarios  exercised  during  the  FYOl  demonstration,  the  SCS  decision 
aids  recommended  first  an  indirect  fire  attack  from  the  compartment  above  the  PDA. 
The  indirect  attack  was  recommended  to  cool  the  fire  spaces,  thereby  minimizing  the 
threat  of  fire  spread  and  improving  the  environment  for  a  direct  attack.  The  SCS 
decision  aids  then  recommended  an  access  to  the  PDA.  If  information  in  the  SCS 
indicated  ali  accesses  to  the  PDA  were  damaged  or  inaccessibie,  the  decision  aids 
recommended  that  a  DC  team  cut  an  access  into  the  PDA.  An  attack  team  then 
entered  the  PDA  via  the  cut  access  for  a  direct  attack  on  the  fires.  Although  the  FYOl 
performance  of  fire  extinguishment  in  37  minutes  did  not  meet  the  DC-ARM  objective  of 
33  minutes,  the  performance  was  close  to  the  objective  and  better  than  the  Baseline 
and  FYOO  performance  of  62  minutes  and  40  minutes  respectively. 

2.4  Fire  Main  Rupture  Isoiation 

Fire  main  rupture  isolation  is  critical  because  setting  manual  fire  boundaries  and 
initiating  manual  fire  attack  cannot  occur  if  the  fire  main  is  not  operational.  The  SCS 
monitors  the  fire  main  conditions  using  information  supplied  by  sensors  in  Smart  Valves 
(also  developed  under  the  DC-ARM  program)  installed  on  the  fire  main.  Both  the  Smart 
Valves  and  the  SCS  are  capable  of  rupture  detection  and  isolation  independently.  For 
the  FYOl  SCS  demonstration,  the  SCS  was  used  as  the  primary  rupture  detection  and 
isolation  mechanism,  with  the  Smart  Valve  device  level  logic  (rupture  path  logic) 
operating  as  a  backup  to  the  SCS  [6].  In  the  FYOl  Demonstration,  the  SCS  isolated  the 
rupture  and  restored  fire  main  pressure  to  the  undamaged  areas  in  just  over  a  minute. 
This  is  a  significant  improvement  from  the  Baseiine  Demonstration  where  it  took  over 
13  minutes  to  manually  locate  and  isolate  the  same  fire  main  ruptures,  using  fire  main 
controi  simiiar  to  that  in  DDG  51  Ciass  ships. 

2.5  DC  Management 

Also  important  is  the  subjective  evaluation  of  the  DC  Officer's  management  and  control 
of  the  situation.  During  the  FYOl  Demonstration,  DC  Centrai  operated  in  a  very 
efficient  manner,  it  was  clear  that  the  DC  Officer  had  good  situation  awareness,  was 
confident  in  the  ability  of  his  people  and  systems,  and  in  control  of  the  situation.  This  is 
an  improvement  over  the  situation  during  the  FYOO  Demonstration  (with  less  situation 
awareness  and  no  automation)  and  a  significant  improvement  over  the  Baseiine 
Demonstration  when  there  was  more  confusion  and  much  less  situation  awareness. 

3.0  SCS  Functions 

The  SCS  performs  the  following  functions: 

•  Controls  the  fire  main 

•  Controls  the  water  mist  system 

•  Provides  fire  aiarm  and  fire  characterization  information 
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•  Provides  video  surveiliance  of  compartments 

•  Provides  access  closure  information 

•  Provides  for  the  entry  of  information  from  verbal  reports 

•  Provides  a  simulated  combat  system  interface  with  threat  status  information 

•  Provides  the  ability  to  define  operational  priorities  that  would  influence  DC  priorities 

•  Provides  displays  to  characterize  damage 

•  Provides  decision  aids  to  assist  with  managing  the  DC  response 

•  Provides  casualty  simulation  to  facilitate  training 

Each  of  these  functions  and  the  DC  central  arrangement  are  summarized  below. 

The  SCS  logical  functions  and  displays  were  "human  engineered."  There  are  two  basic 
parts  to  this  human  engineering  process.  First,  is  a  rigorous  method  for  determining 
the  functions  that  personnel  must  perform  and,  thereby,  determining  the  information 
that  they  need  to  perform  those  functions.  Second,  is  the  structure  and  format  of  the 
displays  so  that  the  information  is  provide  to,  or  obtained  by,  the  user  in  a  natural, 
intuitive  manner. 

The  functional  analysis  method  used  to  define  functions  is  described  in  section  5.1. 
Established  human  factors  guidance  for  human-computer  interfaces  was  studied, 
tailored  to  shipboard  DC  functions,  and  applied  to  the  development  of  the  SCS  displays. 
Rapid  prototypes  of  various  display  formats  were  tested  and  evaluated  by  personnel 
independent  from  the  development  and  selected  display  formats  and  structures  were 
tested  with  Fleet  personnel  experienced  in  DC. 

As  a  result  of  the  comprehensive  attention  to  human  engineering  design,  the  displays 
proved  to  be  quite  intuitive  and  natural  for  Fleet  users.  Personnel  typically  became 
proficient  at  difficult  tasks  with  very  little  training  and  were  able  to  easily  retrieve 
information  they  wanted.  Most  importantly,  the  SCS  clearly  enabled  the  user  to  achieve 
superior  situation  awareness  and  management  of  the  DC  response. 

3.1  Fire  Main  Control 

See  Figure  1;  the  SCS  provides: 

•  A  human  engineered  interface  for  enabling  situation  awareness  of  the  fire  main 
status  and  for  remote  control  of  the  fire  main.  This  includes  decision  aids  for 
isolating  fire  main  ruptures  (if  device  level  and  system  level  controls  fail)  and  for 
alerting  the  DC  Officer  of  inoperable  fire  plugs.  The  system  display  is  integrated 
with  compartment  status  information  to  assist  the  DC  Officer  with  the  difficult  task 
of  integrating  systems  information  and  compartment  information. 

•  Redundant,  survivable  system  level  control  to  isolate  fire  main  ruptures.  This  was 
the  primary  means  of  isolating  fire  main  ruptures  during  DC-ARM  exercises. 
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•  Interface  with  the  Smart  Valve  device  level  controls  for  isolating  fire  main  ruptures. 
The  Smart  Valves  provide  a  highly  survivable,  robust  rupture  isolation  capability 
should  communications  or  system  level  controls  fail.  The  Smart  Valves  were 
developed  by  another  DC-ARM  project  [6]. 
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Figure  1,  Fire  Main  Control  Display 


3.2  Water  Mist  Control 

See  Figure  2;  the  SCS  provides: 

•  A  human  engineered  interface  for  enabling  situation  awareness  of  the  water  mist 
system  status  and  for  remote  control  of  the  water  mist  system. 

•  Automatic  control  of  the  water  mist  system  for  fire  suppression  and  fire 
containment.  This  automation  is  based  on  fire  characterization  and  fire  growth 
models  in  the  SCS  [7],  [8]  and  [9]. 
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Figure  2.  Water  Mist  Control  Display 


3.3  Fire  Alarm  and  Fire  Characterization 

The  SCS  interfaces  with  the  fire  detection  system  to  alert  the  operator  to  fire  alarms 
[10].  And,  the  SCS  interfaces  with  the  SHADWELL's  instrumentation  system  to  obtain 
thermocouple  data  for  characterizing  fires.  The  fire  characterization,  based  on  fire 
growth  models  and  available  thermocouple  data,  is  used  to  support  decision  aids  for  the 
type  of  response  appropriate  to  the  fire,  the  level  of  personnel  protection  needed  and 
the  need  for  and  location  of  fire  boundaries. 


3.4  Video  Surveillance 

The  SCS  interfaces  with  the  SHADWELL's  video  system  and  enables  the  operator  to 
select  compartment  videos  to  display.  The  video  system  also  automatically  delivers 
images  related  to  the  damage  event  to  assist  the  DC  Officer  make  a  rapid  assessment 
of  the  situation.  The  FYOO  test  concluded  that  video  surveillance  would  be  a  significant 
contribution  to  situation  awareness.  The  FYOl  test  confirmed  that  integrated  streaming 
video  was  extremely  beneficial  in  the  DC  Officer's  understanding  of  the  casualty.  It 
allowed  the  DC  Officer  a  first  hand  view  of  the  entire  area  surrounding  the  PDA, 
complementing  the  on-scene  investigator's  reports.  Using  the  integrated  video,  the  DC 
Officer  was  able  to  continually  monitor  the  areas  surrounding  the  PDA  faster  than 
investigators  would  be  able  to  navigate  around  the  PDA  and  report  back  to  the  DC 
Officer  providing  quicker  visual  situational  awareness  than  through  only  on-scene 
investigation. 
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3.5  Access  Closure  Monitoring 

The  SCS  interfaces  with  the  access  closure  monitoring  system  to  display  the  status  of 
access  closures  [11]. 

3.6  Data  Entry 

The  SCS  provides  a  human  computer  interface  tailored  to  entering  status  data  obtained 
from  verbal  reports.  Past  experience  with  computerized  DC  information  systems 
demonstrated  the  need  for  an  interface  that  enabled  the  rapid,  accurate  entry  of  data 
from  verbal  reports.  To  meet  this  need,  the  SCS  includes  a  display  engineered  to 
support  the  rapid  entry  of  data  from  verbal  reports  following  standard  convention  for 
DC  reports. 

3.7  Threat  Status  from  Simulated  Combat  Systems  Interface 

The  SCS  provides  a  simulated  interface  with  combat  systems  to  alert  personnel  to  the 
threat  status  and  to  predict  damage  from  an  incoming  threat  weapon  (see  Figure  3). 
The  predicted  threat  information  is  used  for  decision  aids  such  as  stationing  personnel 
away  from  the  threat  trajectory  (i.e.  stationing  personnel  on  the  port  side  when  the 
threat  is  from  the  starboard  side). 


Combat  Systems 
Situation 
Summary 

Bogey 

Description 

Warhead  Size 


Time  to  Enter 
Strike  Range 
(sec) 

Is  Attack  Likely? 

Time  to  Impact 
(sec) 

Impact  Side 


Figure  3.  Pre-Hit  Information 
3.8  Define  Operational  Priorities 

The  SCS  provides  the  user  with  the  ability  to  define  priorities  among  operational 
elements  (maintain  mission  capability,  save  the  ship,  minimize  risk  to  personnel).  The 
defined  operational  priorities  influence  DC  priorities  as  follows.  Individual 
compartments  are  ranked  in  importance  to  each  operational  element.  Decision  aids 
then  recommend  DC  actions  based  on  the  importance  of  associated  compartments 
relative  to  the  selected  operational  priorities.  For  example,  if  minimizing  risk  to 
personnel  is  given  a  very  high  priority  relative  to  other  operational  elements,  then 
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controlling  damage  in  passageways  and  major  accesses  (for  escape  and  rescue  and 
assistance)  would  be  given  a  higher  priority  than  controlling  damage  in  combat  systems 
spaces  (see  Figure  4). 


Operational 

Elements 


Importance  of 
Operational  Elements 
to  Current  Mission 


Figure  4.  Operational  Priorities 


3.9  Characterize  Damage 

The  SCS  provides  human  engineered  displays  of  compartment  damage  (i.e.,  fire, 
flooding,  smoke  and  blast  damage)  and  the  status  of  DC  actions  (i.e.,  setting 
boundaries  and  fire  attack)  (see  Figure  5).  Systems  information  also  can  be  shown  on 
this  display  although  typically  system  information  is  not  shown. 
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using  Human 
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with  more  than 
90%  smoke 
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Boundary 
maintained 
using  WaterMist 

Maintained 
Boundary  Segment 

Boxmdary 
maintained 
using  Human 


Figure  5.  Compartment  Damage 


3.10  Decision  Aids 

The  SCS  provides  decision  aids  to  help  the  DC  Officer  coordinate  the  actions  of 

personnel  with  the  actions  of  ship  systems  (see  Figure  6).  Decision  aids  include 

functions  such  as: 

•  The  type  of  personnel  protection  required  for  fire  attack  teams  considering  the  state 
of  the  fire,  predicted  fire  growth,  and  the  time  needed  for  personnel  to  reach  the 
scene. 

•  The  need  for  manual  boundaries  considering  the  predicted  fire  growth,  the  status  of 
water  mist,  and  the  importance  of  the  compartment  to  operational  priorities. 

•  Priorities  for  investigators  considering  the  estimated  extent  of  damage  and  the 
availability  of  video  in  compartments  in  and  around  the  damage  area. 

•  Provided  a  course  of  action  to  attack  the  PDA  based  on  the  human  resources 
available  and  the  current  situation.  The  SCS  will  continually  refine  its  decisions  and 
recommendations  as  the  scenario  evolves,  taking  into  account  the  effectiveness  (or 
non-effectiveness)  of  personnel  assigned  to  a  particular  task  or  a  change  in 
environmental  conditions. 
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Figure  6.  Initial  Decision  Aids  for  a  Typical  Wartime  Scenario 


3.11  Simulation  and  Training 

The  SCS  was  designed  with  a  training  feature  that  allows  users  to  exercise  the  SCS 
against  hypothetical  scenarios.  Each  scenario  is  designed  around  a  blueprint  of  the 
primary  damage  area  and  an  assumed  initial  compartment  temperature  around  the 
blast  area.  Each  scenario  can  begin  with  simulated  prehit  information  similar  to  how  an 
actual  live  fire  test  would  begin.  Upon  missile  impact,  the  simulator  drives 
environmental  variables  (thermocouple  and  smoke  density  data)  in  the  common 
database.  The  SCS  reacts  to  this  simulated  data  in  the  same  manner  as  it  would  react 
to  true  environmental  data.  The  simulator  also  recreates  damaged  and  malfunctioning 
sensors  to  add  an  additional  degree  of  realism  to  the  scenario.  The  SCS  will  proceed  as 
it  would  for  a  real  situation  controlling  simulated  water  mist  and  fire  main  valves.  The 
simulator  then  responds  to  the  SCS  countermeasures  by  adjusting  the  environmental 
sensor  data  to  reflect  the  performance  of  the  installed  systems,  (i.e.  thermocouple 
temperatures  decrease  when  the  SCS  turns  on  water  mist  in  a  compartment,  or 
temperatures  increase  and  fires  spread  if  the  user  disables  water  mist  in  a 
compartment.)  The  simulator  can  be  operated  by  one  person,  who  can  also  be 
responsible  for  simulating  the  actions  of  DC  personnel  on-scene,  giving  the  SCS  user  a 
full  scenario  experience.  This  simulator  was  used  successfully  for  familiarizing  fleet 
personnel  with  the  SCS  in  preparing  for  the  FYOl  Demonstration  week. 


3.12  DC  Central  Arrangement 

The  workstations  and  displays  in  DC  Central  are  arranged  in  a  human  engineered  layout 
to  enable  effective  situation  awareness  and  management  of  the  DC  response  with  three 
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people  in  DC  Central:  a  communications/data  entry  operation,  a  workstation/ship 
systems  operator,  and  the  DC  Officer  (see  Figure  7). 


Realtime  Video 
Display  of  images 
from  casualty  area 

DC  Officer’s 
SCSView 

DC  Console 
Operator’s 
SCSView 

DC  Communications/ 
Plotter  Operator’s 
SCSView 


Figure  7.  DC  Central  Photo  from  FYOl  Demonstration 


4.0  SCS  Architecture 

A  moduiar  software  architecture  is  used  for  the  SCS  so  that  the  extent  of  redundancy 
and  separation  implemented  in  a  particular  installation  can  be  adjusted  to  the  degree  of 
survivabiiity  required  and  the  resources  avaiiable  (more  redundancy  and  separation 
wouid  improve  survivabiiity,  but  would  cost  more  to  implement).  The  architecture  of 
the  software  modules  is  consistent  with  the  DC  functions.  There  are  separate  software 
moduies  for: 

•  A  generic  Compartment  Module 

•  A  Zone  Module  for  each  watertight  subdivision 

•  A  module  for  each  system  (i.e.  a  Fire  Main  Module  and  a  Water  Mist  Module) 

•  A  Top  Level  Module  for  human-computer  Interface  and  personnel  management 
logic  and 

•  A  Database  Server  Module. 

Each  of  the  application  software  moduies  is  designed  to  operate  on  a  separate 
computer,  or  they  can  operate  on  one  computer  or  a  combination  of  computers.  All  of 
the  computers  that  are  running  application  software  modules  communicate  over  a  data 
network.  Each  SCS  applications  computer  has  a  complete  set  of  SCS  applications 
software,  but  loads  and  runs  only  its  designated  application  software  module  (or 
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modules),  thereby  keeping  the  processor  burden  low  and  the  execution  speed  high.  If 
the  designated  primary  computer  for  an  application  module  fails,  the  application 
automatically  executes  on  the  another  SCS  computer.  For  example,  the  primary  fire 
main  control  was  run  on  a  separate  computer  for  the  FYOl  Demonstration.  If  the 
primary  fire  main  computer  was  lost,  one  of  the  remaining  SCS  computers  would  load 
its  copy  of  the  fire  main  control  module  from  its  hard  drive  and  begin  monitoring  fire 
main  components  and  making  fire  main  decisions  automatically. 

In  the  event  a  previously  lost  computer  comes  back  online  or  a  new  computer  is 
started,  the  computer  with  the  most  modules  running  will  offload  applications  to  the 
new  computer,  thereby  distributing  the  processing  load,  keeping  the  response  of  the 
system  high,  and  restoring  redundancy  and  separation. 

The  Database  Server  Module  provides  data  to  and  obtains  data  from  all  of  the 
applications  and  provides  the  interface  with  other  systems,  such  as  the  SHADWELL 
instrumentation  system.  The  Database  Server  Module  could  have  been  made 
redundant  with  commercially  available  database  replication  software.  Due  to  the 
expense  involved,  such  database  replication  software  was  not  utilized  for  the  FYOl 
Demonstration  SCS. 

5.0  Engineering  the  Architecture  of  Distributed  Control  Systems 

It  is  not  unusual  for  projects  that  implement  complex  control  systems  to  experience 
cost  overruns  and  schedule  delays.  Then,  even  after  the  added  time  and  expense  and 
substantial  changes  to  the  system,  the  system  still  does  not  perform  as  expected.  Such 
performance  problems  usually  are  exacerbated  when  the  system  operates  in  off-design 
conditions  or  equipment  fails.  Such  experiences,  which  are  probably  representative  of 
the  state-of-the-art  in  industry  today,  indicate  that  designing  a  control  system  to 
support  DC  (when  off-design  conditions  and  equipment  failures  are  to  be  expected)  is 
at  the  edge  of,  or  exceeding,  the  state-of-the-art.  An  objective  of  the  DC-ARM 
program,  therefore,  is  not  only  to  demonstrate  technology  to  enable  reduced  DC 
manning  and  improved  DC  performance,  but  to  provide  a  methodology  for 
implementing  the  demonstrated  technology  aboard  Navy  ships.  The  key  to  successful 
implementation  of  distributed  control  systems  to  function  in  a  DC  environment  is 
rigorous  engineering  of  the  architecture  of  the  distributed  control  system. 

The  basic  steps  used  for  the  DC-ARM  SCS  development  to  engineer  the  architecture  of 
the  distributed  control  system  included: 

1.  Defining  the  control  decisions  that  will  be  executed  by  the  system. 

2.  Developing  the  control  decision  logical  architecture. 

3.  Defining  candidate  hardware  and  software  architectures. 

4.  Evaluating  the  candidate  hardware  and  software  architectures  and  selecting  the 
optimum. 
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Each  of  these  steps  is  described  briefly  below. 

5.1  Defining  the  Control  Decisions  Executed  by  the  System 

The  first  step  in  engineering  the  architecture  of  the  distributed  control  system  is 
defining  and  understanding  the  control  decisions  that  will  be  executed  by  the  system. 

In  a  system  such  as  the  DC-ARM  SCS  where  people  must  interact  closely  with  the 
systems  being  controlled,  a  human-centered  approach  to  the  design  is  vital  to  the 
effective  operation  of  the  system.  A  functional  analysis  methodology  was  used  to 
define  the  control  decisions  that  are  executed  by  the  SCS  and  the  information  that  the 
SCS  displays  to  the  DC  Officer.  The  functional  analysis  also  provides  an  integrated 
definition  of  DC  functions  performed  by  personnel  and  by  ship  systems.  The  process  of 
developing  the  functional  analysis,  and  the  resulting  product,  also  provide  both  the  user 
and  the  developer  with  a  clear,  detailed  understanding  of  the  performance  to  be 
expected  from  the  control  system  (see  Figure  8). 


Figure  8.  Sample  Functional  Analysis  for  Firefighting 
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5.2  Developing  the  Control  Decision  Logical  Architecture 

The  second  step  in  engineering  the  architecture  of  a  distributed  control  system  is 
understanding  the  logical  architecture  of  the.  control  decisions.  This  understanding  of 
the  logical  architecture  is  essential  to  making  subsequent  decisions  about  the 
architecture  of  the  hardware  and  software  that  will  result  in  an  effective,  robust, 
survivable  distributed  control  system  that  is  practical  to  develop,  install,  and  maintain. 

For  the  DC-ARM  SCS,  three  levels  were  defined  for  the  architecture  of  the  control 
system  logic  (other  control  applications  could  define  different  levels  for  the  logic 
architecture): 

1.  Device  Level  Control  Logic  is  logic  that  requires  inputs  only  from  the  device 
itself  to  make  the  control  decision.  For  example,  the  DC-ARM  Smart  Valve 
required  only  data  from  pressure  sensors  installed  in  the  valve  itself  to  make 
the  control  decision  to  close  to  isolate  a  rupture.  A  typical  electrical  circuit 
breaker  and  a  conventional  pressure-regulating  valve  are  other  examples  of 
the  application  of  device  level  logic.  Similarly,  from  a  compartment  perspective, 
compartment  level  control  logic  V40o\^  require  inputs  from  only  one 
compartment  to  make  the  control  decision. 

2.  System  Level  Control  Logic  is  logic  that  requires  inputs  from  more  than  one 
device  in  the  system  to  make  the  control  decision.  For  example,  using  flow 
balance  among  multiple  sensing  points  in  a  fluid  system  to  identify  a  rupture  is 
system  level  logic.  Similarly,  from  a  compartment  perspective,  zone  level 
control  logic  yNQu\(ii  require  inputs  from  more  than  one  compartment  in  a  zone. 

3.  Ship  Level  Control  Logic  reo^mes  inputs  from  more  than  one  system,  or  more 
than  one  zone,  or  a  combination  of  systems  and  zones  to  make  the  control 
decision.  For  the  DC-ARM  SCS,  any  control  decision  involving  actions  by 
people  is  considered  ship  level  control  logic. 

It  is  very  important  to  keep  in  mind  that  this  is  a  logical  architecture,  it  is  not  a 
definition  for  the  architecture  of  the  software  or  hardware  that  processes  the  control 
decisions.  Figure  9  is  an  example  of  the  logical  architecture  for  fire  main  control. 
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Ship  Level  Logic  requires 
input  from  more  than  one  system. 
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Figure  9.  Example  Logical  Architecture  for  Fire  Main  Control 


5.3  Defining  Candidate  Hardware  and  Software  Architectures 

The  control  decision  logical  architecture  provides  the  basis  for  the  synthesis  of 
candidate  hardware  and  software  architectures  that  meet  the  same  functional 
requirements.  Factors  such  as  processor  load,  communications  load,  survivability 
requirements,  and  cost  constraints  should  be  considered  in  synthesizing  candidate 
hardware  and  software  architectures.  Experience  in  developing  the  DC-ARM  SCS 
provided  the  following  lessons: 

•  Defining  boundaries  for  applications  software  modules  consistent  with  the 
levels  in  the  control  logical  architecture,  and  consistent  with  the  boundaries  in 
the  functional  analysis,  provide  a  software  architecture  that  is  naturally  easy  to 
understand.  This  simplifies  the  development  of  the  software  and  will  greatly 
simplify  the  maintenance  of  the  software. 

•  Executing  device  level  logic  at  the  device  level  (sensors,  processor,  and 
actuator  all  part  of  the  device)  provides  a  very  robust  (system  functions  with 
multiple  device  failures),  highly  survivable  control  capability.  True  device  level 
control  (executing  device  level  logic  on  device  level  processors)  also  inherently 
supports  "plug  and  play"  upgrades  to  the  system.  Unfortunately,  true  device 
level  control  could  not  be  achieved  for  many  of  the  necessary  control 
decisions. 
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•  Executing  system  level  logic  or  ship  ievei  iogic  on  device  ievei  processors,  on 
the  other  hand,  would  likely  result  in  a  control  system  with  a  very  high 
communications  load  (hampering  response  during  a  casualty  when  the  data 
rate  is  high),  and  in  a  control  response  that  would  likely  be  difficult  to  predict. 
Such  an  approach  also  makes  it  extremely  difficult  to  achieve  a  robust 
capability  (i.e.  a  system  that  would  function  in  spite  of  multiple  device  failures). 

•  Utilizing  a  hardware  architecture  that  mirrors  the  control  decision  logical 
architecture  would  provide  a  hardware  architecture  that  is  naturally  easy  to 
understand,  thereby  simplifying  development  and  maintenance  of  the  system. 
This  also  would  lead  to  the  maximum  level  of  survivability  that  could  be 
achieved  for  the  control  decisions  that  need  to  be  executed.  Combining  levels 
of  control  decisions  in  higher-level  processors  (i.e.  executing  system  level  logic 
in  a  ship  level  computer)  is  practical  and  could  reduce  the  cost  of  the  system. 

5.4  Evaluating  the  Candidate  Hardware  and  Software  Architectures  and  Selecting  the 
Optimum 

The  candidate  hardware  and  software  architectures  could  be  evaluated  against  program 
selection  criteria  (relative  priorities  for  survivability,  cost,  robustness,  maintainability, 
and  other  program  criteria)  to  select  the  architecture  that  is  optimum  for  the  program. 
For  the  FYOl  Demonstration,  the  SCS  was  distributed  across  several  PCs.  For 
performance  reasons,  four  PCs  were  used  in  Damage  Control  Central  (DCC)  to  run  the 
SCS  graphical  displays:  One  PC  for  the  DC  Communications/Plotter  Operator,  one  PC 
for  the  DC  Console  Operator,  and  two  PCs  for  the  DC  Officer.  One  of  the  DC  Officer's 
PCs  ran  the  standard  SCS  graphical  interface,  and  the  other  PC  was  dedicated  to 
running  streaming  video  from  the  test  area.  Remotely  there  were  three  PCs  responsible 
for  all  of  the  SCS  data  synthesis.  Each  PC  ran  1/3  of  the  software  modules,  thus  evenly 
distributing  the  workload  amongst  the  three  PCs.  Three  PCs  were  sufficient  to  prove 
the  concept  of  the  distributed  control  system  and  the  dynamic  application  reallocation 
discussed  in  Section  4.0.  The  SCS  display  software  is  separated  from  the  logic  software 
so  multiple  display  stations  can  be  used  throughout  the  ship,  and  to  achieve  responsive 
SCS  displays. 

There  was  a  common  database  using  Microsoft  SQL  Server  7.0,  which  maintained  all  of 
the  SCS  information.  No  attempt  was  made  to  develop  a  survivable  database  scheme, 
because  database  software  manufactures  have  developed  successful  methods  of 
database  replication.  For  the  purposes  of  the  demonstration,  database  replication  was 
not  demonstrated  but  it  should  be  noted,  that  it  is  available  and  would  be  required  to 
make  the  complete  system  survivable. 
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6.0  Conclusions 


The  DC-ARM  demonstration  has  shown  how  the  SCS,  functioning  with  other  DC-ARM 
technologies  such  as  water  mist,  can  be  integrated  into  a  ship's  overall  DC  capability  to 
reduce  DC  manpower  while  improving  DC  performance.  Realistic,  full  scale  fire  and 
damage  scenarios,  conducted  with  Fleet  personnel  using  the  SCS  and  performing  DC 
actions  were  utilized  to  measure  and  validate  the  effectiveness  of  the  DC-ARN 
technology.  The  DC-ARM  technologies  met  most  of,  and  in  many  cases  exceeded,  the 
quantitative  requirements  established  to  significantly  reduce  DC  manning  and  improve 
DC  performance.  Tasks,  such  as  controlling  fires,  that  took  on  the  order  of  an  hour 
with  conventional  methods  were  accomplished  in  tens  of  minutes  with  DC-ARM 
technology;  and  tasks,  such  as  identifying  the  PDA,  that  took  tens  of  minutes  with 
conventional  methods  were  accomplished  in  seconds  with  DC-ARM  technology.  By 
identifying  the  PDA,  automatically  restoring  damaged  fire  main,  and  automatically 
establishing  fire  boundaries  within  the  first  minute  after  a  casualty,  the  DC-ARM 
technology  dramatically  improves  the  ship's  capability  to  contain  and  control  a  casualty. 
Consequently,  fire  spread  is  reduced,  injuries  are  reduced,  equipment  damage  is 
reduced,  and  fight-through  is  improved,  all  with  the  utilization  of  substantially  fewer 
personnel  for  DC. 

The  DC-ARM  program  demonstrated  DC  manning  and  performance  with  the  following 
stages  of  technology  applied: 

1.  Baseline  Demonstration:  Improved  doctrine  and  existing  technology  aboard 
Navy  ships. 

2.  Remote  Manual  Control  Demonstration:  Remote  manual  control  of  key 
systems  and  improved  instrumentation  and  information  systems  to  enable 
improved  situation  awareness. 

3.  Automated  Demonstration:  Automated  responses  to  damage,  where 
practical,  integrated  with  complementary  manual  actions. 

These  staged  demonstrations  provide  the  Navy  with  benchmarks  of  technology  risk,  DC 
manning,  and  DC  performance  that  can  be  used  to  determine  the  balance  that  best 
suits  a  particular  program  for  upgrading  existing  ships  or  for  designing  new  ships. 

In  addition  to  demonstrating  the  reduced  manning  and  improved  performance  that  can 
be  achieved  with  DC-ARM  technology,  the  DC-ARM  program  defined  and  applied  a 
design  methodology  for  the  SCS  and  integrated  systems  that  will  enable  the  successful 
application  of  DC-ARM  technology  to  a  specific  ship  design. 
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7.0  Recommendations 


A  triad  of  testing  should  be  used  to  fully  exercise  any  new  DC  system  before  it  is 
introduced  fleet-wide.  A  recommended  test  protocol  would  include: 

1.  Testing  in  a  realistic  DC  environment  with  Fleet  personnel,  such  as  the  testing 
typically  conducted  aboard  the  SHADWELL,  This  testing  already  has  been 
conducted  for  the  DC-ARM  SCS. 

2.  Testing  aboard  an  active  ship.  Given  the  rigorous  engineering  methods  used 
to  develop  the  SCS  and  the  extensive,  realistic  testing  used  to  demonstrate 
the  effectiveness  of  the  SCS,  the  SCS  is  considered  ready  for  pilot  testing 
aboard  an  active  ship.  Such  a  pilot  installation  could  be  a  fairly 
straightforward  application  of  the  capabilities  demonstrated  aboard  the 
SHADWELL  (compartment  information  for  firefighting  and  DC  and  control  of 
the  fire  main  and  other  installed  firefighting  systems),  or  the  pilot  installation 
could  be  extended  to  include  other  ship  systems. 

3.  Weapon  effects  testing  of  the  vulnerability  of  the  systems.  The  SCS  and 
integrated  distributed  controls  for  systems  such  as  the  fire  main,  could  be 
tested  at  facilities  such  as  the  Army  proving  grounds  at  Aberdeen,  MD,  or 
they  could  be  installed  aboard  a  decommissioned  ship  used  for  full-scale  live- 
fire  tests.  Including  the  DC-ARM  SCS  and  distributed  controls  in  such  testing, 
which  is  conducted  periodically  by  the  Navy,  would  provide  valuable  lessons 
for  the  application  of  this  technology  to  DC  functions  that  must  be  performed 
after  a  ship  takes  damage. 

Although  it  is  unlikely  that  any  system  or  capability  related  to  DC  today  has  been 
subjected  to  such  a  triad  of  testing,  conducting  such  tests  in  a  coordinated  manner, 
would  provide  a  high  degree  of  confidence  that  the  expected  DC  performance  would  be 
realized  in  practice.  Of  these  tests,  the  SHADWELL  testing  (item  1.)  probably  is  the 
most  demanding,  realistic  representation  of  the  DC  environment  in  which  people  and 
systems  must  interact;  the  DC-ARM  SCS  is  the  only  Navy  information  and  control 
system  that  has  gone  through  such  tests.  Most  of  the  DC  information  and  control 
systems  being  installed  aboard  ships  today  have  only  gone  through  pilot  testing  aboard 
active  ships  (item  2.).  Such  pilot  Fleet  testing  is  important,  but  cannot  replicate  the 
demands  and  stresses  of  a  realistic  DC  environment.  Weapon  effects  testing  (item  3.), 
typically  has  not  been  performed  for  DC  systems  being  installed  aboard  ships  today. 

Such  testing  would  provide  confidence  that  the  systems  would  perform  as  expected 
after  the  ship  is  damaged. 

Conducting  such  a  triad  of  tests  for  the  DC-ARM  SCS  is  recommended  so  that  ship 
designers  have  the  comprehensive  lessons  learned  to  effectively  apply  the  technology 
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and  so  that  the  Fleet  has  confidence  that  these  new  capabilities  will  perform  as 

expected  when  they  are  needed  the  most. 

8.0  References 

1.  Williams,  F.W.,  Nguyen,  X.,  Buchanan,  J.,  Farley,  J.P.,  Scheffey,  J.L,  Wong,  J.  T., 
Pham,  H.V.,  Toomey,  T.A.,  "ex-USS  Shadwell {[SD-\S)—l\\e  Navy's  Full-Scale 
Damage  Control  RDT&E  Test  Facility,"  NRL  Memorandum  Report  8576,  August  24, 
2001. 

2.  Wiiliams,  F.W.,  Tatem,  P.A.,  Nguyen,  X.,  Durkin,  A.,  Parker,  A.J.,  Strehlen,  B.D., 
Scheffy,  J.L,  Pham,  H.,  Wong,  J.T.,  Darwin,  R.L,  Runnerstrom,  E.,  Lestina,  T., 
Downs,  R.,  Bradley,  M.,  Toomey,  T.A.,  Farley,  J.P.,"Results  of  1998  DC-ARM/ISFE 
Demonstration  Tests,"  NRL  Formai  Report  9929,  April  25,  2000. 

3.  Peatross,  M.J.,  Luers,  A.C.,  Pham,  H.V.,  Scheffey,  J.L.,  Wong,  J.T.,  Farley,  J.P., 
Williams,  F.W.,  Tatem,  P.A.,  Nguyen,  X.,  Rose-Pehrsson,  S.L.,  "Results  of  the  FY 
2000  DC-ARM  Demonstration,"  NRL  Letter  Report  6180/3905,  January  31,  2001. 

4.  Bradley,  M.,  Burns,  S.,  Downs,  R.,  Lestina,  T.,  Roberts,  M.,  Runnerstrom,  E.,  Yufik, 
Y.M.,  Seridan,  T.,  Williams,  F.W.,  Tatem,  P.A.,  "DC-ARM  Supervisory  Control  System 
Development:  Phase  1,"  NRL  Memorandum  Report  8468,  June  26,  2000. 

5.  Runnerstrom,  E.,  Dixon,  T.R.,  "Operational  Objectives  for  Firefighting,'"  NAVSEA 
03R1,  November  1997. 

6.  Lestina,  T.,  Bradley,  M.,  Downs,  R.,  Runnerstrom,  E.,  Durkin,  A.,  Williams,  F.W., 
Farley,  J.,  "Development  of  DC-ARM  Reflexive  Smart  Valve,"  NRL  Memorandum 
Report  8552,  May  7,  2001. 

7.  Bradley,  M.K.,  Roberts,  M.,  Runnerstrom,  E.,  "DC-ARM  SCS  Fire  Characterization, 
Rev.  1,"  MPR  Calculation  353-010-MKB-l,  1/17/01. 

8.  Downs,  R.,  Lestina,  T.,  "Supervisory  Control  Development,  Scoping  Calculation  of 
Heat  Transfer  and  Space  Temperatures  for  Water  Mist  Boundary  Cooling,"  MPR 
Calculation  RPD-353-9801-011-01, 11/17/00. 

9.  Bradley,  M.,  Downs,  R.,  Runnerstrom,  E.,  "DC-ARM  Supervisory  and  Control  System, 
Determination  of  Temperature  Limits  for  Boundary  Cooling  Actuation,"  MPR 
Calculation  353-017-MKB-l,  11/00 


21 


10.  Wright,  M.T.,  Gottuk,  D.T.,  Wong,  J.T.,  Pham,  V.P.,  Rose-Pehrsson.  S.L.,  Hart,  S. 
Hart,  S.,  Hammond,  M.  Williams,  Tatem,  P.A.  and  Street,  T.,  "Prototype  Early 
Warning  Fire  Detection  System:  Test  Series  3  Results,  "NRL  Memorandum  Report 
8592,  December  19,  2001. 

11.  Mai,  M.T.,  Robertson,  R.A.  and  Williams.,  F.W.,  "Conceptual  Evaluation  of  Static 
and  Variable  Resistance-Based  Closure  Sensors,"  NRL  Letter  Report  6180/0066, 
April  20,  2000. 


22 


